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Requirements for Operations, Administration, and Maintenance (OAM) 
in Transparent Interconnection of Lots of Links (TRILL) 
Abstract 
Operations, Administration, and Maintenance (OAM) is a general term 
used to identify functions and toolsets to troubleshoot and monitor 
networks. This document presents OAM requirements applicable to the 
Transparent Interconnection of Lots of Links (TRILL). 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6905. 
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Les 


T: 


Introduction 


The Operations, Administration, and Maintenance (OAM) generally 
covers various production aspects of a network. In this document, we 
use the term OAM as defined in [RFC6291]. 


The success of network operations depends on the ability to 
proactively monitor it for faults, performance, etc., as well as the 
ability to efficiently and quickly troubleshoot defects and failures. 
A well-defined OAM toolset is a vital requirement for wider adoption 
of Transparent Interconnection of Lots of Links (TRILL) as the next 
generation data-forwarding technology in larger networks such as data 
centers. 


In this document, we define the requirements for TRILL OAM. It is 
assumed that the readers are familiar with the OAM concepts and 
terminologies defined in other OAM standards such as [8021ag], 
[RFC5860], and [RFC4377]. This document does not attempt to redefine 
the terms and concepts specified elsewhere. 


1. Scope 


The scope of this document is OAM between Routing Bridges (RBridges) 
of a TRILL campus over links selected by TRILL routing. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
Although this document is not a protocol specification, the use of 
this language clarifies the instructions to protocol designers 
producing solutions that satisfy the requirements set out in this 
document. 


Terminology 


Section: This term refers to a segment of a path between any two 
given RBridges. As an example, consider the case where RB1 is 
connected to RBx via RB2, RB3, and RB4. The segment between RB2 to 
RB4 is referred to as a section of the path RB1 to RBx. More details 
of this definition can be found in [RFC5960]. 


Flow: This term indicates a set of packets that share the same path 
and per-hop behavior (such as priority). A flow is typically 
identified by a portion of the inner payload that affects the hop-by- 
hop forwarding decisions. This may contain Layer 2 through Layer 4 
information. 
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All Selectable Least-Cost Paths: This term refers to a subset of all 
potentially available least-cost paths to a specified destination 
RBridge that are available (and usable) for forwarding of frames. It 
is important to note that in practice, due to limitations in 
implementations, not all available least-cost paths may be selectable 
for forwarding. 


Connectivity: This term indicates reachability between an arbitrary 
RBridge RB1 and any other RBridge RB2. The specific path can be 
either explicit (i.e., associated with a specific flow) or 
unspecified.  Unspecified means that messages used for connectivity 
verification take whatever path the RBs happen to select. Please 
refer to [OAMOVER] for details. 


Continuity Verification: This term refers to proactive verification 
of liveliness between two RBridges at periodic intervals and the 
generation of explicit notification when connectivity failures occur. 
Please refer to [OAMOVER] for details. 


Fault: This term refers to an inability to perform a required action, 
e.g., an unsuccessful attempt to deliver a packet. Please refer to 
[TERMTP] for definition. 


Defect: This term refers to an interruption in the normal operation, 
such that over a period of time no packets are delivered 
successfully. Please refer to [TERMTP] for definition. 


Failure: This term refers to the termination of the required function 
over a longer period of time.  Persistence of a defect for a period 
of time is interpreted as a failure. Please refer to [TERMTP] for 
definition. 


Simulated Flow: This term refers to a sequence of OAM-generated 
packets designed to follow a specific path. The fields of the 
packets in the simulated flow may or may not be identical to the 
fields of data packets of an actual flow being simulated. However, 
the purpose of the simulated flow is to have OAM packets of the 
simulated flow follow a specific path. 


4. OAM Requirements 

4.1. Data Plane 
OAM frames, utilized for connectivity verification, continuity 
checks, performance measurements, etc., will by default take whatever 


path TRILL chooses based on the current topology and per-hop equal- 
cost path choices. In some cases, it may be required that the OAM 
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frames utilize specific paths. Thus, it MUST be possible to arrange 
that OAM frames follow the path taken by a specific flow. 


RBridges MUST have the ability to identify frames that require OAM 
processing. 


TRILL OAM frames MUST remain within a TRILL campus and MUST NOT be 
egressed from a TRILL network as native frames. 


OAM MUST have the ability to include all Ethernet traffic types 
carried by TRILL. 


4.2. Connectivity Verification 
4.2.1. Unicast 


From an arbitrary RBridge RB1, OAM MUST have the ability to verify 
connectivity to any other RBridge RB2. 


From an arbitrary RBridge RB1, OAM MUST have the ability to verify 
connectivity to any other RBridge RB2 for a specific flow via the 
path associated with the specified flow. 


4.2.2. Distribution Trees 


OAM MUST have the ability to verify connectivity from an arbitrary 
RBridge RB1 to either a specific set of RBridges or all member 
RBridges, for a specified distribution tree. This functionality is 
referred to as verification of the unpruned distribution tree. 


OAM MUST have the ability to verify connectivity from an arbitrary 
RBridge RB1 to either a specific set of RBridges or all member 
RBridges, for a specified distribution tree and for a specified flow. 
This functionality is referred to as verification of the pruned tree. 


4.3. Continuity Check 


OAM MUST provide functions that allow any arbitrary RBridge RB1 to 
perform a Continuity Check to any other RBridge. 


OAM MUST provide functions that allow any arbitrary RBridge RB1 to 
perform a Continuity Check to any other RBridge using a path 
associated with a specified flow. 


OAM SHOULD provide functions that allow any arbitrary RBridge to 


perform a Continuity Check to any other RBridge over any section of 
any selectable least-cost path. 
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OAM SHOULD provide the ability to perform a Continuity Check on 
sections of any selectable path within the network. 


OAM SHOULD provide the ability to perform a multicast Continuity 
Check for specified distribution tree(s), as well as specified 
combinations of distribution trees and flows. The former is referred 
to as an unpruned multi-destination tree Continuity Check and the 
latter is referred to as a pruned tree Continuity Check. 


4.4. Path Tracing 


OAM MUST provide the ability to trace a path between any two RBridges 
corresponding to a specified unicast flow. 


OAM SHOULD provide the ability to trace all selectable least-cost 
paths between any two RBridges. 


OAM SHOULD provide functionality to trace all branches of a specified 
distribution tree (unpruned tree). 


OAM SHOULD provide functionality to trace all branches of a specified 
distribution tree for a specified flow (pruned tree). 


4.5. General Requirements 


OAM MUST provide the ability to initiate and maintain multiple 
concurrent sessions for multiple OAM functions between any arbitrary 
RBridge RB1 to any other RBridge. In general, multiple OAM 
operations will run concurrently. For example, proactive continuity 
checks may take place between RB1 and RB2 at the same time that an 
operator decides to test connectivity between the same two RBs. 
Multiple OAM functions and instances of those functions MUST be able 
to run concurrently without interfering with each other. 


OAM MUST provide a single OAM framework for all TRILL OAM functions 
within the scope of this document. 


OAM, as practical and as possible, SHOULD reuse functional, 
operational, and semantic elements of existing OAM standards. 


OAM MUST maintain related error and operational counters. Such 
counters MUST be accessible via network management applications 
(e.g., SNMP). 


OAM functions related to continuity and connectivity checks MUST be 
able to be invoked either proactively or on demand. 
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OAM MAY be required to provide the ability to specify a desired 
response mode for a specific OAM message. The desired response mode 
can be in-band, out-of-band, or none. 


The OAM Framework MUST be extensible to include new functionality. 
For example, the solution needs to include a version number to 
differentiate older and newer implementations and TLV structures for 


flexibility to include new information elements. 


OAM MAY provide methods to verify control-plane and forwarding-plane 
alignments. 


OAM SHOULD leverage existing OAM technologies, where practical. 
4.6. Performance Monitoring 
4.6.1. Packet Loss 


In this document, the term "packet loss" is used as defined in 
Section 2.4 of [RFC2680]. 


OAM SHOULD provide the ability to measure packet loss statistics for 
a flow from any arbitrary RBridge RB1 to any other RBridge. 


OAM SHOULD provide the ability to measure packet loss statistics over 
a section for a flow between any arbitrary RBridge RB1 to any other 
RBridge. 


OAM SHOULD provide the ability to measure packet loss statistics 
between any two RBridges over all least-cost paths. 


An RBridge SHOULD be able to perform the above packet loss 
measurement functions either proactively or on demand. 


4.6.2. Packet Delay 


There are two types of packet delays -- one-way delay and two-way 
delay (Round-Trip Delay). 


One-way delay is defined in [RFC2679] as the time elapsed from the 
start of transmission of the first bit of a packet by an RBridge 
until the reception of the last bit of the packet by the destination 
RBridge. 
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Two-way delay is also referred to as Round-Trip Delay and is defined 
similar to [RFC2681]; i.e., the time elapsed from the start of 
transmission of the first bit of a packet from RB1, receipt of the 
packet at RB2, RB2 sending a response packet back to RB1, and RB1 
receiving the last bit of that response packet. 


OAM SHOULD provide functions to measure two-way delay between two 
RBridges. 


OAM MAY provide functions to measure one-way delay between two 
RBridges for a specified flow. 


OAM MAY provide functions to measure one-way delay between two 
RBridges for a specified flow over a specific section. 


4.7. ECMP Utilization 


OAM MAY provide functionality to monitor the effectiveness of per-hop 
Equal-Cost Multipath (ECMP) hashing. For example, individual 
RBridges could maintain counters that show how packets are being 
distributed across equal-cost next hops for a specified destination 
RBridge or RBridges as a result of ECMP hashing. 


4.8. Security and Operational Considerations 


Methods MUST be provided to protect against exploitation of OAM 
framework for security and denial-of-service attacks. 


Methods MUST be provided to prevent OAM messages from causing 
congestion in the networks.  Periodically generated messages with 
high frequencies may lead to congestion, hence methods such as 
shaping or rate limiting SHOULD be utilized. 


Certain OAM functions may be utilized to gather operational 
information such as topology of the network. Methods MUST be 
provided to prevent unauthorized users accessing OAM functions to 
gather critical and sensitive information of the network. 


OAM packets MUST be limited to within the TRILL campus, and the 
implementation MUST provide methods to prevent leaking of OAM packets 
out of the TRILL campus. Additionally, methods MUST be provided to 
prevent accepting OAM packets from outside the TRILL campus. 


4.9. Fault Indications 
OAM MUST provide a Fault Indication framework to notify the packet's 


ingress RBridge or other interested parties (such as syslog servers) 
about faults. 


Senevirathne, et al. Informational [Page 8] 


RFC 6905 TRILL OAM Requirements March 2013 
OAM MUST provide functions to selectively enable or disable different 
types of Fault Indications. 

4.10. Defect Indications 
OAM SHOULD provide a framework for Defect Detection and Indication. 


OAM Defect Detection and Indication Framework SHOULD provide methods 
to selectively enable or disable Defect Detection per defect type. 


OAM Defect Detection and Indication Framework SHOULD provide methods 
to configure Defect Detection thresholds per different types of 
defects. 

OAM Defect Detection and Indication Framework SHOULD provide methods 
to log defect indications to a locally defined archive (such as log 
buffer) or Simple Network Management Protocol (SNMP) traps. 

OAM Defect Detection and Indication Framework SHOULD provide a Remote 
Defect Indication framework that facilitates notifying the 
originator/owner of the flow experiencing the defect, which is the 
ingress RBridge. 

Remote Defect Indication MAY be either in-band or out-of-band. 


4.11. Live Traffic Monitoring 


OAM implementations MAY provide methods to utilize live traffic for 
troubleshooting and performance monitoring. 


5. Security Considerations 


Security requirements are specified in Section 4.8. For general TRILL 
security considerations, please refer to [RFC6325]. 
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